fix: timed calibration lost on reconfigure reload (v1.3.1)#8
Merged
Conversation
The timed-calibration flow aborted with reconfigure_successful, which reloads the config entry and rebuilds the cover from the calibration Store. The cover's _save_calibration was fire-and-forget and raced the reload, so the rebuilt cover read an empty Store and fell back to DEFAULT_TRAVEL_TIME (60s) — a drive-to-% then used 60s instead of the calibrated time. _emit_calibration_signal now awaits _save_calibration before emitting the signal and aborting, so the Store is durable when the reload rebuilds the cover. Adds a regression test exercising the full calibrate -> reload-rebuild -> set-position path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a regression in v1.3.0 where a calibrated timed (non-bidirectional) motor drives to a target position using the 60s default travel time instead of the calibrated time — observed as a 25% close running ~15s (0.25 × 60) instead of ~6.25s (0.25 × 25).
Root cause
The timed-calibration flow aborts with
reconfigure_successful, which makes Home Assistant reload the config entry and rebuild the cover from the calibration Store. The cover persisted calibration via a fire-and-forgethass.async_create_task(_save_calibration(...)), which raced the reload — so the rebuilt cover read an empty Store and fell back toDEFAULT_TRAVEL_TIME(60s). (Confirmed empirically: the user saw the entity flicker on save = the reload.)Fix
options_flow_timed_calibration._emit_calibration_signalnowawaits_save_calibration(...)to the Store before emitting the signal and before the reconfigure abort, so the write is durable by the time HA reloads and rebuilds the cover. Mirrors the bidirectional flow. Root-cause fix at the calibration source, not the symptom.Tests
tests/test_cover.py::test_timed_calibration_survives_reconfigure_reloaddrives the real calibrate → reload-rebuild → set-position path (the prior test set_travel_time_opendirectly and missed this). RED before the fix, GREEN after.Patch release: 1.3.0 → 1.3.1.
🤖 Generated with Claude Code